Add ASan/TSan sanitizer support and CI jobs#98
Add ASan/TSan sanitizer support and CI jobs#98siddimore wants to merge 2 commits intolivekit:mainfrom
Conversation
siddimore
commented
Apr 15, 2026
- Add LIVEKIT_SANITIZER CMake option (address, thread, undefined)
- 'address' enables ASan + UBSan with -fno-omit-frame-pointer
- 'thread' enables TSan
- 'undefined' enables UBSan standalone
- Blocked on Windows (MSVC lacks TSan/UBSan); works on Linux and macOS
- Add linux-debug-asan and linux-debug-tsan CMake presets with corresponding build and test presets
- Add 'sanitizers' CI job in builds.yml with ASan and TSan matrix
- Fix reversed markdown link syntax in README.md
- Add LIVEKIT_SANITIZER CMake option (address, thread, undefined) - 'address' enables ASan + UBSan with -fno-omit-frame-pointer - 'thread' enables TSan - 'undefined' enables UBSan standalone - Blocked on Windows (MSVC lacks TSan/UBSan); works on Linux and macOS - Add linux-debug-asan and linux-debug-tsan CMake presets with corresponding build and test presets - Add 'sanitizers' CI job in builds.yml with ASan and TSan matrix - Fix reversed markdown link syntax in README.md
The TSan CI job referenced tsan_suppressions.txt with a relative path, which resolved against the test binary directory instead of the repo root. - Create tsan_suppressions.txt with Rust FFI suppressions - Use $GITHUB_WORKSPACE absolute path in TSAN_OPTIONS
| - name: Build | ||
| run: cmake --build --preset ${{ matrix.preset }} | ||
|
|
||
| - name: Run unit tests |
There was a problem hiding this comment.
Hi there @siddimore: can you explain the decision to make this a separate stage (Sanitizer - <arch>) vs. incorporating the sanitizer steps into the existing build steps?
There's a lot of duplication in setup here, and definitely a tradeoff between parallelizing the workflow vs. too much duplication.
There was a problem hiding this comment.
That is a fair point since this was my first PR in this repo wanted to tread carefully plus these other reasons:
- ASan/TSan require recompilation with different flags (-fsanitize=address vs -fsanitize=thread), so you can't just re-run existing binaries
- Existing matrix includes macOS and Windows, which don't need sanitizer runs
- Isolation — a TSan failure shouldn't block the macOS or Windows build result
but i m happy to avoid the duplication which u identified in the setup which is the right call. I will update the PR later today. Thanks for your review
There was a problem hiding this comment.
Hello again, I actually thought more about your PR after my original comment, and for sure the different compiler flags make a difference. For context, I am working on a "quality build" stage that ideally could handle the following:
- clang-tidy (open PR)
- sanitizer builds
- code coverage (debug flag builds)
It will probably take a little bit more time for me to fully flesh out that idea and see what stages we could combine configuration/compiler-flag wise. So feel free to iterate on your PR here, but we will probably want to bundle that in later with the other quality items. Stay tuned, thanks!